feat(tasks): surface an OpenCode pane's subagents like Claude Code's - #1987

Merge Risk: Low · up to d6e68

The OpenCode subagent feature looks sound overall. A narrow race in the task route can briefly show a stale session's tasks. On Windows, a subagent left by a crashed OpenCode service is not shown as lost, and the guide does not say so. Both are small, bounded fixes that can be made before or shortly after merge.

Pre-merge checks: 5

Check name	Status	Explanation
Title check		The title "feat(tasks): surface an OpenCode pane's subagents like Claude Code's" matches the main change. The PR adds OpenCode subagent counts, lists, BG turn status, lost detection, and result cards,…
Linked Issues check		The PR addresses all coding requirements in [#893]. OpencodeSubagentStatus reads OpenCode child sessions, counts running subagents, and supplies the task list. The route and client expose counts, th…
Out of Scope Changes check		The changes stay within [#893]. Server tracking, status integration, route selection, task-result conversion, client display, translations, documentation, changelog entries, and regression tests direc…
Docstring Coverage		Docstring coverage is 87.50% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 32 functions across 21 files. (2 skipped: 2…
Description check		The pull request description is complete and on topic. It explains the problem and resulting behavior, links issue #893, describes implementation details and known limits, and provides detailed valida…

Full details: Title check

Explanation

The title "feat(tasks): surface an OpenCode pane's subagents like Claude Code's" matches the main change. The PR adds OpenCode subagent counts, lists, BG turn status, lost detection, and result cards, all in the tasks and status code paths. The title is concise, specific, and follows a conventional-commit style.

Full details: Linked Issues check

Explanation

The PR addresses all coding requirements in [#893]. OpencodeSubagentStatus reads OpenCode child sessions, counts running subagents, and supplies the task list. The route and client expose counts, the newest ended tasks, and the omitted-running count. server/core/status.ts maps running work to BG and coordinates the completion alert. Pane and session checks mark work as lost when the pane no longer runs the session. server/opencode.ts creates an ended-task card with the answer and removes the foreground <subagent> wrapper. The reported unit, contract, and browser tests cover these behaviors.

Full details: Out of Scope Changes check

Explanation

The changes stay within [#893]. Server tracking, status integration, route selection, task-result conversion, client display, translations, documentation, changelog entries, and regression tests directly support OpenCode subagent surfacing. Paging, stale-read handling, busy-store handling, and omitted-task reporting support correct lifecycle behavior and large-task-set handling. No unrelated product behavior is identified.

Full details: Docstring Coverage

Explanation

Docstring coverage is 87.50% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 32 functions across 21 files. (2 skipped: 2 unsupported.)

Full details: Description check

Explanation

The pull request description is complete and on topic. It explains the problem and resulting behavior, links issue #893, describes implementation details and known limits, and provides detailed validation results including unit, contract, status-hub, browser, and fast-check coverage.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

CodeRabbit hit its review limit on this PR, so no CodeRabbit review ran. The code-review agents' reviews of this head stand in. Their findings and how each was resolved:

omo-native-code-reviewer, the rebased diff (onto #1848 and #1842): approve

• LOW: a Claude-held BG wait could survive a direct Claude→OpenCode switch, because OpenCode's reset was vetoed by Claude's not-yet-refreshed state. Fixed: OpenCode's first session after another agent resets, and which tracker speaks for a pane follows the newest snapshot (owns in server/core/status.ts).
• LOW: the subagent contract case read the machine's own OpenCode service.json. Fixed: the case runs on its own server with an empty openCodeStateDir and waits for its status subscription, and the tracker reads the service from openCodeStateDir.
• LOW: the guide said a subagent reads as lost when OpenCode's service stops. Fixed: it reads as lost once another service starts or the pane leaves the session, and the guide now says that.
• LOW: service.json is read on every 2 s poll. Declined: omo.ts and prompt.ts read it the same way.

Codex (gpt-6.1-sol, xhigh), the rebased diff: two MEDIUMs, both reproduced, both fixed

• A session found only after the turn that started its subagent had ended lost that turn's rest, so the pane read DONE while the child ran. Fixed: a pane's first session resets only when the pane ran another agent until then (server/opencode-subagents.ts ensure), plus a unit case.
• An incoming Claude session inherited OpenCode's BG hold: Claude's reset was vetoed by the outgoing OpenCode tracker's stale live. Fixed: agentNow, each pane's agent from the newest snapshot (set before either tracker reads it) or status event, decides owns.
• The shared pane mute (feat(alerts): share one pane mute across alert channels #1848) and the detail sheet (feat(tasks): inspect running Claude subagent details #1842, now detail_kind: null for OpenCode tasks) checked out.

Re-review of those fixes

• Codex Sol's re-review did not run: it stalled twice on the host before starting.
• omo-native-code-reviewer re-reviewed the fixes and approved, with no blockers.
• LOW, fixed: a route's Claude lookup (plan or background-agent) between snapshots could still meet the old veto. A status event's agent now counts too.
• LOW, fixed: a dead line in the contract case.
• LOW, declined: if another agent runs in a pane, then an OpenCode turn starts and ends with no snapshot taken in between, the first-session reset drops that turn's rest. Claude's own reset does the same on main.

How the fixes were checked

• A QA script, kept out of the repo, drives the real createStatusHub through clientSnapshot, with herdr's collector and snapshot, the OpenCode service and the Claude lookup stubbed. It passes 7/7: both Codex scenarios, the route variant, and the Claude→OpenCode switch.
• Reverting each fix makes its case fail.
• On c706a7aa0: contract 21/21, and browser QA passed at 1440x900 and 390x844.

Merge pass review of c706a7a. The Astra gate (omo-native-gate-reviewer, gpt-6-astra) rejected it on three blockers it reproduced.

What holds:

• 158 targeted tests pass (52/52 locally), and typecheck is clean.
• No authorization bypass was found.
• The QA results and the six desktop/mobile screenshots were inspected.

BLOCKER C2: polling blocks the event loop (server/core/status.ts:132-135, server/opencode-subagents.ts:267-272; report E1)

• On macOS, every live poll runs a synchronous /bin/ps with a 1000 ms timeout.
• Separately, a real SQLite contention probe blocked the Linux event loop for 251 ms.
• Fix: run the per-poll path asynchronously and keep it off synchronous subprocess or DB waits, the same as fix(server): read macOS process starts and terminals from the kernel, and await name lookups' git #1980 does for the other paths.

BLOCKER C3: BG is reported as DONE when the session is discovered late (server/opencode-subagents.ts:255; report E2)

• The case: an OpenCode turn follows another agent and finishes before its session is discovered. The first binding then clears the rest it observed.
• What happened: the real status hub returned DONE, background_tasks=1, no background_wait, and sent done to the alert sink while the child was still running.
• Fix: carry the observed state across the first binding, so a turn whose subagent still runs reads BG and alerts once, when the subagent ends.

BLOCKER O1/O2: the count and the running list miss running subagents behind the cap (server/opencode-subagents.ts:106-122; report E3)

• The 1024-child cap applies before children are classified by status.
• One older running child plus 1024 newer completed children returned running=0, and the running child was missing from the list.
• Fix: find all running children first, or classify before applying the cap. Add a regression test for it.

This PR touches server/, so it merges only after the 0.4.18 Release run. The re-review will cover only the new commits.

Heads-up: an OpenCode subagent can go idle before it is done (anomalyco/opencode#57418)

runEnd takes a child session's newest idle row as the end of the subagent. That matches OpenCode 2.1.4 today, but the open upstream PR anomalyco/opencode#57418 ("fix(core): wait for background jobs before reporting subagent result") changes when a subagent is done:

• A child can go idle while background work it started still runs (a background shell, or its own background subagents). Its idle row is written at that point.
• With #57418, the parent's subagent call is answered only after that work ends and the woken child goes idle again. A foreground call's tool block in the parent stays running until then; a background call's synthetic wake row (metadata.source: "subagent") arrives only then.

Once #57418 ships, this PR reads such a subagent as completed while the parent is still waiting on it: the running count drops, the BG hold is released, and the turn is alerted as DONE once the 60 s grace runs out, while the work goes on. The child's next run (rows after its first idle) then reads as running again, so the list flips back and forth. Before #57418 this reading happens to match, since the parent is answered at the first idle and a child woken again reads as running.

A reading that holds before and after #57418, the way claude-subagents.ts takes ends from the parent transcript: take the end from the parent session's record, and use the child's idle row only as a fallback.

• Foreground call: the parent's subagent tool block (state.metadata.sessionID names the child) ends with its own status: completed with a metadata.status other than running, or error (error.type: "aborted" is a cancel).
• Background call: answered at once with metadata.status: "running", ended by the parent's synthetic row carrying metadata.childID and metadata.state (completed, cancelled, error).
• The newest of call and notice wins, so a call that resumes a child (sessionID in its input) runs it again.
• The child's own idle row decides only for a child that was woken after the parent was told it ended, or one that no call in the parent names (a migrated 1.x store, or a call older than the window read).

The parent's rows stay cheap to read when SQL filters them first (instr(data, '"name":"subagent"') on assistant rows, instr(data, '"source":"subagent"') on synthetic rows), reading on from the last seq seen and re-reading a row whose call was not answered yet when its time_updated moves.

The row shapes above were checked against a local OpenCode 2.1.4 store (about 1,600 subagent calls written by 2.0.x to 2.1.4).

The three gate blockers are answered in ae1384c and fa86923, two new commits on top of c706a7a. An omo-native-code-reviewer pass on ae1384c approved it; its two MEDIUMs are fixed in fa86923.

C2: polling no longer waits on the event loop

• macOS ps: the OpenCode service's start is now looked up once per service process, with processStartUpperBoundAsync, and cached by pid. No poll runs ps. Until the answer arrives, no run is treated as left behind by an earlier service.
• SQLite: a poll's read uses busy_timeout 0 (withStore takes the wait as a parameter). A store held by its writer now fails the read at once, and the counts stay as they were. The chat and the tasks route keep their 250 ms wait.
• QA: a poll against a store held under BEGIN EXCLUSIVE took 0.1 ms and kept the count. With the 250 ms wait restored, that check fails.

C3: a session found late after another agent now reads BG

• BackgroundWait.resetBefore(pane, since): resets the pane but keeps the rests observed from since on.
• What each reset keeps: the status hub records each pane's agent from its status events, with the time that agent began (eventAgent). When OpenCode's first session follows another agent, the reset keeps OpenCode's rests and drops the other agent's. Claude's reset when the pane leaves Claude does the same, keeping the new agent's rests. A new session of the same agent still resets everything.
• Immediate lookup: a status event from an OpenCode pane whose session isn't known yet now looks the pane up at once (paneGet, then ensure and poll). The turn is held BG within milliseconds. That working cancels the pending finish alert, which waits at least 10 s, so the finish is alerted once, when the subagent ends.
• QA: in a harness on the real status hub, both Claude→OpenCode and Codex→OpenCode read DONE with no background_wait before this commit. Now they read BG before any snapshot, keep BG after it, and end with working. Reverting resetBefore to a plain reset fails all six of these checks. Removing the immediate lookup fails the checks taken before the snapshot.

From the review of ae1384c (fixed in fa86923)

• Stale snapshot after the immediate lookup: a snapshot whose herdr read began before the lookup, but was answered after it, put the pane back to what herdr said then. The lookup's session then came back as a new lifetime and dropped the rest again. Reads are now numbered as they begin (beginRead). The tracker and the hub's view of the pane's agent never take a read that began before one they already took. In the harness this case runs with herdr's answer held back until after the lookup, for both a stale home screen and a stale Claude. It passes now, and ignoring the stamps fails all four checks.
• Poll cost: the split into running and ended children read every child's newest row twice. It is one query again, and the cap on ended children applies after it. On the reviewer's 1100-child benchmark it costs the same as before the split (about 9 ms per read here).
• Service start lookup: it is asked again when it gets no answer, and the store is read again as soon as it answers.

O1/O2: every running child counts

• readSubagents now reads every child whose newest run row is not idle, with no cap, and classifies all of them. Only ended children, which are read for the list, keep the 1024 cap.
• The existing test now has 1030 newer ended children, more than the cap. It counts the older running child and lists it. Restoring the cap fails that test.

@Ploppy3's note on anomalyco/opencode#57418

• Thanks. The current reading matches OpenCode as released (2.1.4): the parent is answered at the child's first idle, and a child woken again reads as running.
• #57418 is still open, so this PR doesn't take it on. Taking ends from the parent's record, as you describe, is the right design once it ships. It's tracked in OpenCode subagents: take a subagent's end from the parent's record, ready for anomalyco/opencode#57418 #1999 with your row shapes and the reading that holds before and after it.

Verification on fa86923

• Unit: 171 pass. Typecheck is clean.
• Status-hub QA harness: 19/19.
• Contract (server/opencode.contract.test.ts, dori heavy): 21/21.
• Browser QA at 1440x900 and 390x844: passes. Checked: BG, "1 background task", badge 1, the detail note, the ended card with its answer, badge 0, and the lost child.
• bun run check fast: green (unit 7203 pass, 0 fail, 24 skip in 487 files, 8 at a time, 66.6s).

Merge pass re-review of fa86923 (Astra gate). The three original reproductions are fixed. Two blockers remain.

Fixed:

• Polling no longer stalls on the process or the lock (E1).
• A turn whose session is found late keeps BG (E2).
• An older child that is still running stays listed (E3).
• The targeted tests pass 160/160 (67/67 locally). The larger child-cap regression fails against c706a7a, and the rest-preservation assertions fail when resetBefore is swapped for reset.
• Coverage still to add: the C2 polling checks and the full C3 status-hub scenario.

BLOCKER C2: the new query loads every child synchronously before applying the cap (server/opencode-subagents.ts:110-119, :293-303; report N1)

• Cause: the SQL LIMIT was removed, so .all() loads every row and .filter() runs afterwards.
• Reproduction: an indexed fixture with 100,000 ended children returned all 100,000 rows and blocked the event loop for 429 ms, even though only ten tasks came out.
• Fix: keep the bound in SQL. Query the running children (unbounded, but few) and the newest ended children (ORDER BY completion time, LIMIT) separately, or page the reads.

BLOCKER O2: the most recently finished child can still go missing (server/opencode-subagents.ts:119, :127-130; report E3b)

• Cause: the cap on ended children picks by creation order before sorting by completion time.
• Reproduction: take E3's older running child and let it finish after all 1,024 newer siblings. It is then left out. The expected first item is that child; the actual first item is ses_done1023.
• Fix: pick the ended children by completion time, ideally in the same bounded SQL query.

This PR touches server/ and conflicts with #1997, so it merges only once it is approved and green. The re-review will cover only the new commits.

Both remaining blockers are answered in f087470 and 75a2ba2. An omo-native-code-reviewer pass on f087470 approved it; its findings are fixed in 75a2ba2. The branch is rebased onto main, so the earlier commits are now b1b2a42, 86cf55b and 669a1e6.

C2 / N1: no read holds the event loop longer than a page

• Cause: measured on your 100,000-child shape, the cost was each child's newest-row lookup, not the rows returned. Keeping the bound in SQL alone still took about 400 ms, so the reads are paged instead.
• The read: it visits a session's children 1000 at a time (SUBAGENT_PAGE, by rowid under parent_id). Whether a child's run ended is told in SQL, the same rule as runEnd. Only the children still running and the ten that ended last are read again in full.
• Rows read again: the rows of the children kept are read again in full a page at a time. Each child's dispatch time and title come in the same read, a listed child's work is read a few children a step, and what each child is is told from sets. The review found that this re-read was one synchronous step: 20,000 children that still ran held the event loop for 625 ms. Now no step takes longer than a page, whatever the children are.
• A poll: it takes each pane's first two steps at once, a page of children and then the rows kept. A session of up to 1000 children, exactly 1000 included, therefore reads whole as before, and a turn's end still finds its subagents in the frame that ends it. A larger session is read a step per turn of the event loop, and its pane is told once the read is whole.
• Panes and busy pages: a pane that leaves its session during such a read is told at once that it runs none. One that moves to another session is read again at once. A step that finds the store busy is tried again on the next turn. The background-tasks route reads the same way (pagedState).
• 100,000 ended children plus one running:
  • the longest event-loop stall during the whole read is 12 ms, against 429 ms before;
  • the read takes about 300 ms in all;
  • it counts the running child exactly, and lists it first.
• 20,000 children that all still run: the longest stall is 13 ms, and all 20,000 are counted.

O2 / E3b: the newest ended child is listed

• The ended children kept for the list are the ten that ended last, by the same end time the list sorts on, not the ten created last.
• The 1030-children test now also ends the older child after all of them, and expects it first on the list. Keeping the ended children in stored order fails that test.

Coverage

• C3: the status-hub half now has a tracked test, server/core/status.test.ts. It runs the real createStatusHub with the collector stood in for, and covers three cases:
  • an OpenCode turn after Claude Code's, held on its subagent before any snapshot and after one, with the finish alert called off;
  • a snapshot whose read began before the immediate lookup but is answered after it;
  • a Claude Code session that follows OpenCode's.
    Reverting the reset that keeps OpenCode's rests, the immediate lookup, the snapshot's agent, or the read stamps each fails it.
• C2: the paging is covered by unit tests:
  • a poll is told the running child only once the last page is in;
  • a session of exactly a page is read at once;
  • more than a page of running children all count;
  • a pane that leaves or switches its session mid-read is told at once.

On 75a2ba2

• Unit tests: 166 pass across the touched suites. Typecheck is clean.
• Contract (server/opencode.contract.test.ts, dori heavy): 21/21.
• Browser QA at 1440x900 and 390x844: passes.
• bun run check fast: green, unit 7213 pass, 0 fail.

The old head's CI was cancelled during the freeze. Any failed job on this push that looks like a known flake (#1994, #2000, #1940) is left for you to rerun.

CI on 75a2ba2 (runs 40306722650, 40306722626) was cancelled whole: every job cancelled, no test failed. Left for the merge pass to rerun in merge order.

Merge pass re-review of 75a2ba2 (Astra gate). Paging and newest-ended are fixed. Three blockers remain.

Fixed:

• N1: the reader now yields between pages. With 100,000 ended children, the longest event-loop gap was 15 ms.
• E3b: the most recent completion is listed first.
• Tests: the targeted tests pass 37/37. The paging, newest-ended and immediate-leave regressions each fail without their fix.

BLOCKER C1: a tasks response can cross a pane or session change (server/opencode-subagents.ts:345-348, server/tasks-routes.ts:44-46; report I1)

• Reproduction: start a request for p1 (session A). While the reader yields, swap p1 to B and p2 to A. The response for p1 still returns A's child.
• Cause: tasksOf never checks its captured binding again after an await.
• Fix: after each await, check that the pane's session binding is still the one captured, and drop the response if it isn't.

BLOCKER P2/C3: retrying a partly read page duplicates children (:187-188, :270-278; report W1)

• Reproduction: a real SQLite writer lock between two full-row reads made the retry add the first child again. Two children came back as running=3, with ids ["ses_a","ses_a","ses_b"].
• Fix: make the retry idempotent. Throw away the partial page, or remove duplicates by id.

BLOCKER C2: the final step still exceeds the page bound (:196-207, :219-239; report N2)

• Reproduction: with 100,000 running children, the final event-loop gap was 128 ms, against 9–10 ms for the pages before it.
• Cause: classification, sorting and building the result handle every retained running child in one synchronous step.
• Fix: cap or page the running set too, or yield during the final step. The result only lists a bounded number anyway.

This PR touches server/ and conflicts with #1997. The re-review will cover only the new commits.

The three blockers from the re-review of 75a2ba2 are answered in ddb0028 and 37e3e4b. An omo-native-code-reviewer pass on ddb0028 approved it; 37e3e4b adds the route test it asked for and drops a check that read it showed was needless.

C2 / N2: no step handles the whole running set

• Each page of the kept children's rows is now classified as it is read: whether the child ended, is lost, or runs, and whether it counts for the turn. So no final step grows with the children.
• Only what the list shows is kept: the newest 1000 running children (RUNNING_LIMIT), listed oldest first, and the ten that ended or were lost last. running and turnRunning still count every child.
• With 100,000 running children, the longest event-loop gap is now about 15 ms (128 ms before), and the count is exact (100,001). With 100,000 ended children it is about 11 ms.

P2 / C3: a retried page takes no child twice

• A page of rows is read whole before any of it is taken. A page that fails part way is therefore read again whole.
• The ids read again hold no child twice. So a page read again after a failure takes no child twice.

C1 / I1: the route answers for the pane as it stands

• tasksOf reads the pane's binding again after the read. If the pane moved to another session, or stopped running it, it reads again for what the pane runs now (up to three times).
• After that read, the route decides again between OpenCode and Claude Code. A pane that runs Claude Code by then is answered with Claude's list.
• Tests:
  • a pane moves to another session while its list is read a page per turn, and the answer is the new session's child;
  • a pane comes to run Claude Code while OpenCode's list is read, and the route answers with Claude's list.
    Each test fails without its re-check.

On 37e3e4b

• Unit tests: 167 pass across the touched suites. Typecheck is clean.
• Contract (server/opencode.contract.test.ts, dori heavy): 21/21.
• Browser QA at 1440x900 and 390x844: passes.
• bun run check fast: green (unit 7214 pass, 0 fail, 24 skip in 488 files, 8 at a time, 59.6s).

Merge pass re-review of 37e3e4b (Astra gate). The I1, W1 and N2 reproductions all pass now. One blocker is left, plus one decision for you.

Fixed:

• I1: a swap mid-read now returns the new session.
• W1: a retry no longer duplicates children.
• N2: the longest event-loop gap fell from 128 ms to 14 ms.
• 38/38 targeted tests pass (74/74 locally). The new binding and OpenCode→Claude route regressions fail against the previous head.
• Still needed: W1 has no committed regression test yet. Please add one.

BLOCKER C1: the route doesn't recheck which pane owns the session (server/tasks-routes.ts:27, :42-53; report I1b/I1c)

• What happens: after awaiting tasksOf, the route only checks that OpenCode is still the selected provider. It never checks that the returned session still belongs to the pane.
• I1b: a swap at that point returned A's child for p1 after p1 had moved to B.
• I1c: a switch from OpenCode to OmO during the read returned the old OpenCode child's "lost" entry. A fresh request correctly returns OmO's empty list.
• Fix: after the await, check that the pane's current session id is the one that was read. If it isn't, throw the result away and answer from the current state, or with nothing.

O2: the new cap drops running tasks from the list (server/opencode-subagents.ts:136, :215, :219; report N2-list)

• What happens: RUNNING_LIMIT=1000 bounds processing by leaving older running children out of the list. With 100,000 running children, the count was right but only 1,000 were listed, with no paging or "and N more".
• Your call: the original requirement caps ended entries at ten, not running ones. A thousand running subagents won't happen in practice. If you keep the cap, say so in the PR and show a "+N more" (the count is already right), and I'll accept it. Otherwise, page the running list.

This PR touches server/ and conflicts with #1997. The re-review will cover only the new commits.

The blocker and the decision from the re-review of 37e3e4b are answered in 2efc9ce and d6e6824, with the branch rebased onto main. An omo-native-code-reviewer pass on the first of the two approved it; d6e6824 adds the two tests it asked for.

C1 / I1b, I1c: the route answers only for what the pane runs after the read

• After each read of an OpenCode list, the route decides again what the pane runs: OmO first, then Claude Code against OpenCode, then which OpenCode session.
• It gives the list only when the pane is still bound to the session that was read (path, session and live alike). tasksOf says which session its list is of, so a list it already read again for the pane's new session is not read a third time. Otherwise the route decides again from the current state, up to three times. A pane that keeps moving gets an empty list, and the client asks again.
• Test, I1b: the pane moves to another OpenCode session while the list is read, and the answer is that session's child.
• Test, I1c: OmO comes to run the pane while OpenCode's tracker still holds the same live session, and the answer is OmO's own task, not OpenCode's list.
• Test, a pane that keeps moving: its session moves on with every read, and after three reads it gets the empty answer.
• Each of these tests fails without its check.

W1: committed regression test

• pagedState takes the store opener as an optional parameter, and the test passes one that throws SQLITE_BUSY once, between the first and the second child's full-row reads.
• The read retries the page whole, and counts and lists each child once.
• Reading the page lazily, taking each child as it is read as before the fix, fails the test.

O2: the cap stays, and the list says what it leaves out

• An OpenCode pane lists the newest 1000 running subagents (RUNNING_LIMIT), and each of them still counts.
• The omo-tasks answer gains an optional more_running, sent only when some are left out, and the list shows "N more running" below the running ones (ja, ko and zh included).
• A bridge from before the field shows no such row.
• The PR body says this.

On d6e6824 (contract and browser QA ran on the same commits before the rebase onto main, which touched none of their code)

• Unit tests (touched suites, after the rebase): 61 pass 0 fail. Typecheck is clean.
• Contract (server/opencode.contract.test.ts, dori heavy): 21/21.
• Browser QA at 1440x900 and 390x844:
  • the original QA passes;
  • with 1004 running subagents, the button reads "1004 background tasks", the list holds 1000, and "4 more running" shows below it.
• bun run check fast after the rebase: green (unit 7260 pass, 0 fail, 24 skip in 488 files, 8 at a time, 64.6s).

#1997 merged as cff839b. This PR conflicts with it in server/core/status.ts and server/index.ts, so please rebase onto main and push once. Only the rebase resolution will be re-checked against the approved 413d11b.

Rebased onto main after #1997 (cff839b) and pushed once: head e9d83c2.

The one conflict was a single hunk in server/core/status.ts, in createStatusHub's options. Both sides are kept: #1997's herdrIdentity and this PR's opencodeDb and openCodeStateDir. server/index.ts merged without a conflict. Nothing else changed from the approved 413d11b.

On e9d83c2:

• Typecheck is clean.
• The touched unit suites pass 85/0, fix(drafts): keep a pane's drafts and lens to the herdr they were made under #1997's finishes tests included.
• server/opencode.contract.test.ts passes 21/21.
• Browser QA passes.
• bun run check fast is green (unit 7310 pass, 0 fail, 24 skip in 494 files, 8 at a time, 59.1s).

Merge pass review report. Overall: PASSED. This PR changes server behaviour and adds a field to an HTTP response (more_running in /api/pane/omo-tasks). The Astra gate (omo-native-gate-reviewer, gpt-6-astra) reviewed it over five rounds and approved d6e6824, then 413d11b.

What it does: an OpenCode pane's subagents now appear in the background-tasks list and the badge, the same way Claude Code's do (#1960-series). The data comes from OpenCode's store, read with herdr's herdr:opencode session binding, never guessed from the working directory.

Findings and how each was resolved:

• E1-E3 (round 1): the store was read synchronously, the session was picked by creation order, and the store was polled once per pane. Fixed: reads now run off the event loop, the session is taken in read order, and one query polls for all panes.

• C2 / N1 (round 2): with no SQL LIMIT, 100,000 children were read in full, blocking for 429 ms. O2 / E3b: the newest ended child was dropped by creation order. Both fixed: reads are paged with a yield between pages (longest gap 15 ms), and the most recently ended child is listed first.

• C1 / I1, P2 / W1, N2 (round 3): an in-flight response crossed a pane or session swap. A retry duplicated children. The final step took 128 ms. All fixed: the binding is checked again after each await, retries are idempotent, and the longest gap is 14 ms.

• C1 / I1b, I1c (round 4): the route checked only the provider, not that the session read still belongs to the pane. Fixed in d6e6824: the route compares its answer with the session that was read. The I1b and I1c regressions fail against the previous implementation.

• O2 (round 4): RUNNING_LIMIT=1000 left running tasks out with no sign. Accepted with the cap disclosed: 1,005 running gives 1,000 listed and more_running: 5. The list shows "N more running", seen in desktop and phone screenshots. The badge count stays exact.

• W1 regression: the retry-deduplication test is now committed, and it fails against the reader before the fix.

• 413d11b (after approval): the route numbers its pane lookup before it waits. In Astra's stale-lookup probe the newer binding was kept, and dropping ensure's second argument brings the overwrite back. The Windows docs sentence matches the code. No committed test checks the route's numbering before the await directly; the existing tracker test covers rejecting a stale number.

Tests: 58 targeted tests pass, and both TypeScript configurations pass. Locally, 75/75 pass and typecheck is clean.

Rebase onto #1997 (e9d83c2):

• Commits: commits 2-10 are unchanged. Commit 1 changed only where it resolves the conflict in server/core/status.ts: the import gains herdrLifetime, and the options gain herdrIdentity next to opencodeDb and openCodeStateDir.
• Nothing from main dropped: I compared backgroundWait, statusNow, herdrIdentity and herdrLifetime between main and the PR, and all are still there.
• Tests: 100 tests pass, including fix(drafts): keep a pane's drafts and lens to the herdr they were made under #1997's paneLifetime and machineSession tests, and typecheck is clean.

Merge pass: main broke after this merged (afdf3a7). The three new server/core/status.test.ts OpenCode-subagent tests fail with 'devices.onPaired' is undefined. #1977 (merged just before) made the status hub call devices.onPaired, and these tests' devices stub ({ gated: false, has: () => true }) doesn't have it. Reverting in #2039 to restore main. To re-land, open a new PR with this PR's change plus onPaired: () => {} in that stub, and nothing else. The approved review carries over, and only the stub change gets re-checked.

Update: rather than reverting, #2040 fixes main forward by adding onPaired: () => {} to this PR's status hub test stub (test-only). The revert #2039 is closed, and this PR's feature stays on main.